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Octet Sequences for Upper-Layer OSI 
to Support Basic Communications Applications 


Status of this Memo 


This memo provides information for the Internet community. This memo 
does not specify an Internet standard of any kind. Distribution of 
this memo is unlimited. 


Abstract 


This document states particular octet sequences that comprise the OSI 
upper-layer protocols (Session, Presentation and ACSE) when used to 
support applications with "basic communications requirements". These 
include OSI application protocols such as X.400 P7 and Directory 
Access Protocol, and "migrant" protocols, originally defined for use 
over other transports. 


As well as the octet sequences which are the supporting layer headers 
(and trailers) around the application data, this document includes 
some tutorial material on the OSI upper layers. 


An implementation that sends the octet sequences given here, and 
interprets the equivalent protocol received, will be able to 
interwork with an implementation based on the base standard, when 
both are being used to support an appropriate application protocol. 
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1. Introduction 


The upper-layer protocols of the OSI model are large and complex, 
mostly because the protocols they describe are rich in function and 
options. However, for support of most applications, only a limited 
portion of the function is needed. An implementation that is not 
intended to be a completely general platform does not need to 
implement all the features. Further, it need not reflect the 
structuring of the OSI specifications - the layer of the OSI model 
are purely abstract. 


This document presents the protocol elements required by the OSI 
upper layers when supporting a connection-oriented application with 
only basic communication requirements - that is to create a 
connection, optionally negotiate the data representation, 
send/receive data, close a connection and abort a connection. 
Optionally, data may be sent on the connection establishment, closing 
and abort messages. 


In this document, the protocol elements needed are given in terms of 
the octet sequences that comprise the ’envelope’ around the 
application data. The envelope and its enclosing data form a 
Transport Service Data Unit (TSDU) that can be passed via the OSI 
Transport Service [1IS08072] (which in turn may be supported as 
specified in [RFC1006] or any class of the OSI Transport Protocol 
[ISO8073]). 
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The octet sequences to be sent and the description of the alternative 
forms that may be received are equivalent to an informal re- 
specification of the relevant parts of the upper-layer protocols. 

The "relevant parts" are determined by the requirements of the 
supported applications (this is a reflexive definition! - if 
application Z needs something that is not here, it is not supported). 
The formal specifications remain the base standards, the appropriate 
profiles and the requirements of the application. However, an 
implementation based on this document will be able to interwork with 
an implementation based directly on the full standards when both are 
supporting a basic communication application. The "full" 
implementation will exhibit only part of its potential behaviour, 
since the application will only invoke part. 


In addition to the octet sequences, the document includes some 
tutorial material. 


2. General 
2.1 Subdivisions of "basic communication applications" 


Distinctions can be made within the "basic communication 
applications", as defined above, based on how much use they make of 
the OSI upper-layer services, and thus how much of the protocol 
described in this memo will be used to support a particular 
application. One distinction is: 


a) whether application data is sent on the connection 
establishment, close and abort, or only during "date phase" 
on an established connection; OR 


b) whether the application data is of only one kind (abstract 
syntax) and one format (transfer syntax) or more than one 
(i.e., how much use is made of the Presentation layer syntax 
negotiation and identification features) 


Further distinctions are possible, but in this memo, elements of 
protocol needed (or not needed) by four groups of "basic 
communications application" are identified. All groups have "basic 
communications requirements" in requiring only connection, data 
transfer and (perhaps) orderly release of connection. The four groups 
are: 


Group I: applications which send data only on an established 
connection, and use a single abstract and transfer syntax. 
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Group II: applications which send data on connection 
establishment and release and use a single abstract and transfer 
syntax. 


Group III: applications that send data of only one kind (one 
abstract syntax) on the connection, but which have more than one 
format (transfer syntax) specified (they use the Presentation 
context negotiation facility). 


Group IV: applications that will send data of several kinds on the 
connection (and which much therefore distinguish on each write 
which kind is being sent). 


Group III applications are equivalent to Group I (or possibly Group 
II) after the establishment exchange has negotiated the particular 
transfer syntax that will be used on the connection. 


Possible examples of the Groups are: 


Group I: Application protocols designed for use over transport- 
level protocols. Typically these are non-OSI protocols "migrated" 
to an OSI environment. X Window System protocol is an example. 


Group II: OSI-originated protocols with simple requirements, 
including many of the ROSE-based ones, such as Directory Access 
Protocol. 


Group III: Protocols that can be treated as Group I, but for 
which more than one encoding of the data is known, such as a 
standardised one and a system-specific one - all implementations 
understand the standard encoding, but Presentation layer 
negotiation allows like-implementations to use their internal 
encoding for transfer, without loss of general interworking. The 
same could apply to OSI protocols. 


Group IV: OSI protocols with multiple abstract syntaxes (but with 
each individual message from a single abstract syntax) that do 
not use any of the special Session functional units - X.400 P7 is 
an example. 


Some of the OSI protocols that are not included are those that use 
more than one abstract syntax in a single message (such as FTAM or 
Transaction Processing) or use Session functional units (RTSE-based 
protocols, Virtual Terminal). 
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2.2 Conformance and interworking 


The protocol elements specified in this memo correspond to the kernel 
functional units of Session, Presentation and ACSE, and the duplex 
functional unit of Session. 


The octet sequences given below are derived from the specifications 
in the International Standards for the protocols Session [1S08327], 
Presentation [IS08822] and ACSE [ISO8650]. The intention of this memo 
is to summarise those specifications, as applicable to the supported 
application groups, so that an implementation could be developed 
without direct reference to the original standards, but capable of 
interworking with implementations that had made direct reference. The 
OSI standards (especially Presentation) allow considerable 
flexibility in the encoding of the protocol data units. Accordingly, 
this memo defines particular octet sequences to be sent, and 
describes the variations that can be expected in data received from 
an implementation based directly on the OSI standards, rather than on 
this cookbook. It is intended that an implementation that sends these 
sequences and that is capable of interpreting the variations 
described will be fully able to interwork with an implementation 
based directly on the OSI standards. An implementation that is only 
capable of interpreting the octet sequences specified in this memo 
for transmission may not be able to interwork with standards-based 
implementations. 


The intent is to be able to interwork with conformant implementations 
in support of the relevant application (or group of applications). 
Some of the OSI standards have conformance requirements that go 
beyond that necessary for successful interworking, including 
detection of invalid protocol. Tests for conformance sometimes go 
beyond the strict conformance requirements of the standard. 
Consequently an implementation based on this memo may or may not be 
able to formally claim conformance to the International Standard. It 
may be able to legitimately claim conformance, but fail a conformance 
test, if the test is over-specified. (Efforts are being made to 
correct this, but in the meantime, the target is interworking with 
conformant implementations.) 


2.3 Relationship to other documents 


The flexibility allowed in the Session, Presentation and ACSE 
standards is restricted in the Common Upper-Layer Requirements Part 1 
[CULR-1]). This is a proposed International Standardised Profile 
(pdISP 11188-1) that can be assumed to be obeyed by most 
implementations. This memo applies the restrictions of CULR-1, 
especially where these concern maximum sizes of fields and the 
like.Points where advantage is taken of a CULR-1 limitation are 
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noted. 


Additional parts of CULR are under development. Part 3 [CULR-3] 
covers the protocol elements needed for "basic communications 
applications", and is being developed in (informal) liaison with this 
memo. CULR-3 is presented as a normal profile, largely consisting of 
prescribed answers to the questions in the PICS (Protocol 
Implementation Conformance Statement) of the three protocols. CULR-3 
does not make the distinction between the four Groups. An 
implementation of this memo (at least if it supported Group IV) would 
be able to claim conformance to CULR-3, with the possible exception 
of any more-than-interworking conformance requirements inherited by 
CULR-3 from the base standards. 


An extension [XTI/mOSI] to the X/Open Transport Interface [XTI] is 
shortly to be published as a preliminary specification. This defines 
an API to the OSI upper-layers, again as appropriate to a basic 
communications application. XTI/mOSI would be usable as an interface 
to support applications in groups I, II and III, and possibly group 
IV, 


3. Contexts and titles 
3.1 The concepts of abstract and transfer syntax 


OSI includes the concepts of "abstract syntax" and "transfer syntax". 
These are terms for the content (abstract syntax) and format "on- 
the-line" (transfer syntax) of the protocol elements. The combination 
of an abstract syntax and transfer syntax is called a presentation 
context. 


Application protocols devised explicitly under OSI auspices have used 
ASN.1 for the definition of the abstract syntax, and nearly all use 
the Basic Encoding Rules applied to the ASN.1 to define the transfer 
syntax. However, there is no such requirement in OSI in general or in 
OSI Presentation, and still less is there any requirement to change 
the representation of existing application protocols to ASN.1 (for 
their definition) or BER (for their transmission). It is not 
generally realised (even in OSI circles) that all communicating 
applications, in all environments, are using some form of these, 
although under different names and without the explicit 
identification that the OSI Presentation provides. OSI separates the 
identification of the content and format of the data from the 
addressing. 


Formal specifications of non-OSI application protocols (such as 


TELNET, FTP, X Windows System) generally do not use ASN.1, but will 
invariably be found to define abstract and transfer syntaxes. For a 
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less formalised protocol used between similar systems, the abstract 
syntax may be defined simply in programming language structures, and 
the transfer syntax determined by how some compiler represents this 
in memory. 


The OSI Presentation protocol requires that "names" be assigned to 
the abstract and transfer syntaxes of the application data that is 
carried. The names are always object identifiers ("oid"): globally 
unique names assigned hierarchically. Presentation supports the 
negotiation of a transfer syntax for a particular abstract syntax - 
several can be offered and one selected. 


This transfer syntax negotiation facility may be especially useful 
for non-ASN.1 syntaxes where there is more than one representation 
available (perhaps differing in byte-ordering or character code). In 
such a case, on the connection establishment, all of the transfer 
syntaxes supported by the initiator are offered, and any one of these 
accepted by the responder, at its own choice. If the two systems 
share some "native" format they can negotiate that, avoiding 
transformation into and out of a more general format that is used for 
interworking with unlike systems. The same applies to an ASN.1- 
defined abstract syntax, but in practice non-BER encodings of ASN.1 
are rare. 


3.2 Use of presentation context by cookbook applications 


An application protocol not originally specified with OSI 
Presentation in mind (a "migrant" protocol) will not normally need to 
identify the abstract and transfer syntaxes being used - they are 
known by some other means (effectively inferred from the addressing). 
A generic (anonymous, if you like) name for both syntaxes can be used 
and [CULR-3] defines object identifiers for "anonymous" abstract and 
transfer syntax names (currently called "default", but this is 
expected to change). 


In some cases object identifier names will be assigned for the 
syntaxes of a migrant application protocol. If these exist, they 
should be used. However, since the processing required will be the 
same, it will be legitimate to offer both the generic and specific 
names, with the responder accepting the specific (if it knew it) and 
the generic if the specific were not known - this will provide a 
migration option if names are assigned to the syntaxes after 
implementations are deployed using the generic names. 


For abstract syntaxes defined in ASN.1 object identifier names will 
have been assigned to the abstract syntax with the specification. 
This name MUST be used to identify the abstract syntax. The transfer 
syntax will most often be the Basic Encoding Rules (BER) object id, 
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but alternatives (e.g., Packed Encoding Rules) are possible. 


For group III and group IV applications, specific object identifier 
names must be used for all the abstract and transfer syntaxes. If 
these names are not assigned with the specification (e.g., if the 
specification not in ASN.1) they can be assigned by whoever needs 
them - ideally the "owner" of the syntax specification. 


3.3 Processing Presentation-context-—definition-list 


In Presentation context negotiation on connection establishment the 
initiator sends a list (the presentation context definition list) of 
the abstract syntaxes it intends to use, each with a list of transfer 
syntaxes. Each presentation context also has an integer identifier. 
To build the reply, a responder has to examine this list and work out 
which of the offered presentation contexts will be accepted and which 
(single) transfer syntax for each. The responder sends back the reply 
field, the Presentation-context-definition-result-list, in the accept 
message. The result list contains the same number of result items as 
the definition-list proposed presentation-contexts. They are matched 
by position, not by the identifiers (which are not present in the 
result- list). An acceptance also includes the transfer syntax 
accepted (as there can be several offered). This can be copied from 
the definition list. 


For the group I, group II and group III cases, only the ACSE and one 
application-data P-context will be used and all other contexts 
rejected. For the group IV case, several presentation contexts will 
be accepted. 


However, even for group I applications there may be synonyms for an 
application-data Presentation-context. Unknown synonyms are rejected. 
The reply shown in 6.2 includes a rejection (It can therefore not be 
the reply to the connection request shown in 6.1, since that has only 
two items in the definition list.) 


In all cases, the connection responder must identify and keep the 
presentation context identifiers (called pcid’s here) for all the 
accepted presentation contexts. These are integers (odd integers, in 
this case). CULR-1 limits them to no greater than 32767, but they 
will usually be <= 255 (so taking up one octet). 


A presentation context is sometimes used (i.e., data is sent using 
it) before the negotiation is complete. As will be seen in section 6, 
in these cases, the transfer syntax name sometimes appears with the 
integer identifier. 
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3.4 Application context 


The Association Control Service Element also exchanges the name 
(another Object Identifier) of the application context, which 
identifies what the communication is all about, again independently 
of the naming and addressing. As for the syntaxes, although some 
name must be present in the protocol, a generic name can be used for 
applications that do not have a specific name assigned. (This will 
almost certainly be a group I application - if a specific name is 
assigned, it must be used.) The only negotiation allowed is that the 
reply may be different from that sent by the initiator. CULR-3 
provides a generic application context name (i.e., assigns an object 
identifier). 


3.5 APtitles and AEqualifiers 


In addition to the addressing constructs (transport address and 
possibly session and presentation selectors), the communicating 
application entities have names - Application-Entity titles 
(AEtitle). These are carried by ACSE as two fields -the 
Application-process titles (APtitle) and the Application-entity 
qualifier (AEqualifier). The AEtitle is compound, and the APtitle 
consists of all but the last element, which is the AEqualifier. (This 
explanation can be run backwards). There are two non-equivalent 
forms. AP-titles and AE-titles can be Directory Name or an Object 
Identifier. AE-qualifiers can be Relative Distinguished Name (RDN) or 
an integer - the forms must match, since the AE-qualifier is the last 
component of the AP-title. In practice, the Directory form is likely 
to be the only one seen for a while. 


Use of the these names is rather variable. This cookbook proposes 
that implementations should be able to handle any value for the 
partner’s names, and set (as initiator) its own names. This is 
primarily to facilitate OSI:non-OSI relaying (e.g., X/osi:X/tcp), 
allowing the names of the end-system to be carried to the relay, 
where they can be converted into hostnames, and the lower-layer 
address determined. OSI assumes that name-to-address lookup is 
possible (via the Directory or other means), but does not assume 
address-to-name will work. Thus the calling AE-title is needed if the 
responder is to know who the initiator is. However, most protocols 
work perfectly well without these names being included. 


As for their encoding, a RDN will almost always be a single attribute 
value assertion, with the attribute defined either by the Directory 
standard [1S09594 = X.500], or in [Internet/Cosine Schema] [RFC1274]. 
Using the notation defined below, the encoding of an RDN using a 
Directory-defined standard attribute is: 
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31 80 (1 — RDN, [SET OF] 
30 80 {2 - AttributeValueAssertion, [SEQUENCE] 
06 03 5504yy -- OID identifying an attribute named in 


—- the Directory standard 
-—- which one is determined by yy 


13 La xxxxxx —-- [Printable string] 

-- could be T61 string, with tag 14 
00 00 }2 - end of AVA 
00 OO }1 - end of RDN 


The most likely attributes for an RDN have the following hex values 
for yy. 


CommonName 03 
Country 06 
Locality 07 
State/Province 08 
Organisation OA 
OrganisationUnit OB 


For non-Directory attributes, the object id name must be substituted 
(thus changing the immediately preceding length) 


If there are multiple attribute value assertions in the RDN, the 
group between {2 and 2} is repeated (with different attributes). 
Order is not significant. 


The encoding of a [Directory] Name for the AP-titles is the RDNs 
(high- order first) within 


30 80 {1 — [SEQUENCE] Name 
—- put the RDN encodings here 
00 00 }1 


An Object Identifier AP-title is encoded as a primitive (see below), 
with the "universal" tag for an object identifier, which is 6. The 
integer AE-qualifier uses the universal tag for an integer, which is 
2 


4. What has to be sent and received 

4.1 Sequence of OSI protocol data units used 
OSI defines its facilities in terms of services but these are 
abstract constructs (they do not have to correspond to procedure 
calls) - the significant thing is the transmission of the resulting 


protocol data unit (PDU). The PDU at each layer carries (as user 
data) the PDU of the layer above. The different layers follow 
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different conventions for naming the pdus. This section gives an 
overview of the sequence of PDUs exchanged - the details of these are 
given in section 6. 


The requirements of the application are to create a connection 
(strictly an association for the application-layer in OSI, but called 
a connection here), to send and receive data and to close the 
connection. The PDUs used are thus: 


To create connection: 
First create transport-level connection 


Initiator sends the message defined in 6.1, which is Session 
CONNECT carrying Presentation CONNECT request [CP] carrying 
ACSE A-ASSOCIATE request [AARQ] optionally carrying application 
data. 


Responder replies with the message defined in 6.2, which is 
Session ACCEPT carrying Presentation CONNECT response [CPA] 
carrying ACSE response [AARE] optionally carrying application 
data. 


- If the responder rejects the attempt, the reply will be Session 
REJECT. This is defined in 6.3, where the REJECT carries no 
user data. A received REJECT may carry Presentation, ACSE and 
application data, although 6.3 shows only how to reject at 
Session level.. 


To send/receive data on an connection 


send the message defined in 6.4, which is an empty Session 
GIVE-TOKEN followed by Session S-DATA carrying Presentation P- 
DATA [TD] containing the application data (The GIVE-TOKEN is 
just two octets required by Session for some backwards 
compatibility.) 


To close connection gracefully 


One side sends the message defined in 6.5, which is Session 
FINISH carrying P-RELEASE request carrying A-RELEASE request 
[RLRQ] optionally carrying application data (This side may now 
receive, but not send data.) 


The other side replies with the message defined in 6.6, which 


is Session DISCONNECT carrying P-RELEASE response carrying A- 
RELEASE response [RLRE] optionally carrying application data 
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First side disconnects transport connection on receiving the 
reply 

To close connection abruptly but also send application data 
Send the message defined in 6.7, which is Session ABORT 
carrying Presentation U-ABORT [ARU] carry ACSE U-ABORT [ABRT] 
carrying application data (delivery not guaranteed) 


On receiving Session ABORT, disconnect transport 


To close connection abruptly 


- Either send the message defined in 6.8, which is Session ABORT 
carrying nothing; 


Or, just disconnect at transport level 


A group I application is assumed (by definition) not to send data on 
the establishment and release exchanges, a group II application will. 


It would be possible to use the abort-with-data facility with a group 
I to send a (possibly non-standardised) error message for diagnostic 
purposes. 


A special rule is used if a release collision occurs (i.e., FINISH+P- 
RELEASE+RLRQ received after sending the same): the side that 
initiated the original upper-layer connection waits and the other 
side replies with the DISCONNECT etc. 


4.2 Which OSI fields are used 


There are a number of fields (parameters) in the pdus involved. These 
can be categorised by what is needed to support applications (of a 
particular Group) in general - a field may be "useful", "send-only", 
"fixed", "fixed with default", "internal" or "not important". Even 
those that are not important may be received from another 
implementation, but since the application has no use for them, they 
can be ignored. If an implementation is intended to support only a 
particular application, it may be able to downgrade the "useful" to 
"not important". 


The text below describes the processing that is required for each 
category and which fields are in each category. 


"Useful" - when sending, an implementation of general use should be 


able to set any (legal) value of these fields (via the upper 
interface from the application or via some configuration or lookup 


Furniss [Page 12] 


RFC 1698 ThinOSI Upper-Layers Cookbook October 1994 


mechanism) and SHOULD pass received values for the Calling values to 
the application (for specific applications, these fields may be 
either required or unnecessary.) 


AARQ: 


Called application-process title 
Called application-entity qualifier 
Calling application-process title 
Calling application-entity qualifier 


"Send-only" - to interwork, the implementation must be able to set 
any value of these, but can ignore any received value. Both are octet 
strings. 


Presentation selector (up to 4 octets, limited by CULR-1) 
Session selector (up to 16 octets, limited by base standard) 


"Fixed" (constant for all applications) 


abstract and transfer syntax identifiers for presentation context 


for ACSE Version numbers - 2 for session, 1 for Presentation 
and ACSE 
"Fixed with default" - the value is specific to the application. For 


non-ASN.1 abstract syntaxes (group I or group II only) applications, 
the anonymous values assigned by the OIW minimal OSI profile [CULR-3] 
can be used. The CULR-3 default application context can be used where 
a proper context name is neither available nor needed. 


Application context 

CULR-3 default is {1 0 11188 3 3} 
Abstract syntax identifier for application data 

CULR-3 anonymous name is {1 0 11188 3 1 1} 
Transfer syntax identifier for application data 

CULR-3 anonymous name is {1 0 11188 3 2 1} 


"Internal" - an arbitrary value can be sent; a received value must be 
stored for use in sending. 


Presentation context identifiers for ACSE and the application 
data (always odd integers) 


"Not important" - for interworking, any legal received value for the 
other fields must be received (i.e., the pdu is parsed successfully), 
but can then be ignored. There is no requirement (in this cookbook) 
to check the existence, value or internal format of these fields. 
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All other fields (which includes a large number of session 
fields) 


4.3 Encoding methods and length fields 


Both Session and ASN.1/BER [1IS08824, IS08825] use a type-length-value 
structure for their encodings, but different ones. Presentation 
protocol and ACSE protocol use the ASN.1/BER encoding and 
consequently a Presentation PDU containing an ACSE PDU can be 
constructed or parsed as if it were a single structure. 


All the protocols contain pdu fields with a compound structure. If 
one of these is being ignored it may be necessary (for BER, not 
session) to determine the lengths of its components to find the 
length of the ignored field. 


Many of the lengths in the specification below will vary, dependent 
on the values of the fields. 


4.3.1 Session items 
The type field of a session item is always a single octet. 


For session items, given a particular length, there is no 
flexibility: 


If the length is less than 255, represent as one octet 


If the length is greater, represent as three octets, first is 
OxFF, next two are the length, high-order octet first. 


(Some "real" implementations are known to use the second encoding in 
all cases. This is wrong, but should only concern conformance 
testers.) 


4.3.2 ASN.1/BER items (Presentation and ACSE) 


The type field for ASN.1-BER is the tag. Although it is possible for 
large tags (>30) to be multi-octet, there are no large tags in the 
protocols involved in this memo. Bit 6 (0x20) of the tag octet is 1 
if the item is constructed (i.e., the value is itself one or more 
ASN.1 BER items) or 0 if it is primitive. 


There is considerable flexibility, at senders option, in how lengths 
are represented in BER. There are three forms: short, long and 
indefinite. 


Short (usable only if the length is less than 127) : one octet 


Furniss [Page 14] 


RFC 1698 ThinOSI Upper-Layers Cookbook October 1994 


Long (usable for *any* length) : first octet has the top bit set, 
the rest is a count of how many octets are holding the length 
value; that many subsequent octets hold the length. A long length 
may use more than the minimum number of octets (so 0x8400000001 
is a valid representation of length 1) 


Indefinite (usable only for the length of a compound field) : the 
single octet is 0x80, then one or more items (their tag-length- 
values) and finally two octets of 0x00 (equivalent to tag and 
length of zero). 


To be able to interwork generally, an implementation must be able to 
handle any of these forms when receiving. 


The encodings specified in the octet sequences below use indefinite 
length for all constructed items with a few exceptions. This slightly 
increases the number of octets sent, but means that the length of a 
varying field (e.g., user data, or a varying object identifier) 
affects only the length of the item itself, and not the enclosing 
lengths. It is thus possible to use the octet sequences as templates 
interspersed by the varying fields. 


It is important to note that this choice of indefinite (which is 
equivalent to the "Canonical Encoding Rules" variant of BER) applies 
only to the Presentation and ACSE protocols themselves. It does not 
apply to ASN.1/BER encoded application data. The processing required 
of application data may suggest alternative "best" options. 


4.4 BER Encoding of values for primitive datatypes 


The following ASN.1 primitive datatypes are used in the thinosi 
stack. 


Integers are encoded in twos-complement, high-order first. Unlike 
lengths, they must be encoded in the minimum number of octets (no 
leading 00 padding). 


Object Identifiers have a rather peculiar, but compressed encoding: 
Combine the first two integers of the OID into one element by 
multiplying the first (always 0, 1 or 2) by 40, and add the 


second. 


Each element (that one, and each subsequent integer in the OID 
taken on its own), is a taken as a binary number and divided into 


7-bit "bytes". This is apportioned into bits 1-7 of the minimum 
number of octets. Bit 8 is one for all octets of the sequence 
except the last. (This means that elements of less than 127 are 
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single octet integers.) 
Printable Strings - as if in ISO 646 (ASCII) 
OCTET STRING - just put the octets there 
4.5 Unnecessary constructed encodings 


BER allows the sender to break some items (such as OCTET STRINGS, 
character strings) into several pieces (i.e., as constructed 
encoding) or send them as primitive. CULR-1 requires that this is 
only done to one level. The pieces of both OCTET STRING and character 
string are tagged as if they were OCTET STRING - they have the tag 
04. This memo does not include any of these optional constructions, 
but they may be received in interworking. 


5. Notation 
The constructs are shown in their tag - length - value form. All 


numbers are in hexadecimal. Comments are preceded by a ’-’ character. 
Multiple ’-’ mean the comment is more than just information. 


The tag column contains one of: 
single fixed octets. 
* in the tag field indicates one or more pdu fields (possibly 
constructed) that may be received but are not sent. If received 
they can be ignored. 
! indicates the tag is defined elsewhere. 


is a place holder for the column. 


? preceding the tag value indicates that the field is not always 
present - the comment will explain. 


The length column contains one of 
explicit value 


Ls - a length according to session rules which depends on the 
total size of the value (usually constructed) 


La - a length according to BER rules 


is a placeholder 
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yy is exactly one octet (i.e., one hex digit per y) holding part 
of the length 


The value column contains one of 


the hex value 

XXXXXX - value of varying length (sometimes constructed) 

{n - (n = number) the start of a constructed value 

n - (n=number) the end of the constructed value with the 
corresponding number. (The number is sometimes omitted on the 


innermost nest of construction) 


yy - as part of a value - a variable value, each y represents one 
hex digit 


? a value, possibly constructed that may be received but is not 
sent. It may be ignored if received 


Note that all presentation lengths may be received in one of the 
alternative forms. All constructed lengths are shown in indefinite 
form. If a received length is definite, the corresponding end item 
(which will be shown here as 00 00 }n) will become .. jn. 


In 


the comments, the notation {n} refers to the constructed item 


bracketed by the {n, }n fields. 


6. Octet sequences 


6.1 Connection request message 


OD 
* 

05 
13 


* 


16 


— CONNECT SPDU 


Ls {1 - "ST" value for CONNECT = 13 

Ls ? -— Connection Identifier 

06 {2 - Connect/Accept Item 

01 00 — protocol options (probably mandatory) 

Ls ? 

Ol 302 —- version number (bottom bit = vl, next bit =v2. 
== may get offers of either or both 

Ls ? 

02 0002 - Session User Requirements (functional units) 
- Id (20), length (always 2), duplex fu only. 
-—- On receipt, other bits may be set 
-- check that the 2 bit is set 

Ls ? - we do not send any Calling Session Selector 
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?34 Ls xxxx -—- Called Session Selector (i.e., the other end’s) 
—-- up to 16 octets - you must set what the other 
-—- side demands. - May be anything characters, 


—- binary etc. 
- {3} disappeared in editing 
C1 Ls {4 -—- User Data, Identifier=193. if length is > 512, 
-—- then identifier is 194 (hex C2) instead 
- CP - P-CONNECT-RI PPDU. Everything below is in ASN.1 BER 
31 80 {5 = [SET] 
--- Mode-selector (the {6} group) could possibly 
-—-- come after everything else {7} 
--- This will probably only be done by 
--- evil-minded conformance testers 


AO 80 {6 —- Mode-selector [0] IMPLICIT SET 

80 01 01 — [0] IMPLICIT INTEGER {normalmode (1) } 
00 00 }6 

A2 La {7 — [2] unnamed IMPLICIT SEQUENCE 

j La ? 

?82 La xxxx - [2] Called-presentation-selector 


- CULR says maximum length is 4 
—- must be what the other side wants 
A4 80 {8 - [4] Presentation-context-definition-list 
--- items (the outer SEQUENCES) within the {8} list may 
--- be in any order. 


30 80 {9 - [SEQUENCE] 

02 OQ1 O12 -—- Defines pcid for ACSE; received value will be 
-- a one or two octet odd integer 

06 04 52010001 - [OID] for ACSE abstract syntax 

30 80 { — [SEQUENCE] 

06 02 5101 - [OID] Transfer syntax name is BER 

00 00 } - end t-s list 

00 00 }9 - end acse pctx defn 

30 80 {10 - [SEQUENCE] 

02 01 03 —- [INTEGER] Defines pcid for application data; 
-—- received value will be a one or two octet odd 
-- integer 

06 La XXXXXX - [OID] object identifier name of application 


abstract syntax (if CULR-3 default is used, this 
- line is 06 06 28D734030101) 


30 80 {11 
06 La XXXXXX - [OID] t-s name for application data 
— (if CULR-3 default is used, this line is 
- 06 06 28D734030201) 
—- will be several of these if multiple t-s offered 
-—- (application is Group IIT) 
-- all will have the same tag 06 
00 00 }11 - end transfer syntax list for application p-ctx 
00 00 310 - end application pctx definition 
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00 
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80 
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-- if multiple presentation contexts are offered, (Group 
—- IV), the {10} SEQUENCE will repeat appropriately 

—-- if multiple contexts are to be accepted, all the 

—- pcid’s must be remembered 


}8 - end of p-ctx-def-list 
2? 
{12 — [APPLICATION 1] User-data - Fully-encoded 
{13 — [SEQUENCE] PDV-list 
01 —- [INTEGER], value is acse pcid 
{14 - [0] Single-ASN1 
A-ASSOCIATE request APDU - AARQ 
{15 — [APPLICATION 0] - AARQ 
? - protocol version defaults to 1 (only one defined) 
{ - [1] Application-context 
XXXXXX -- object identifier name of application context 
— (if CULR-3 default is used, this line is 
- 06 05 28D7340303) 
} 
-—- Called application process title {16} and application 
-- entity qualifier may or may not be needed (see 3.4) 
{16 - [2] Called Application-Process title 
XXXXXX —- see 3.5 - either a Directory Name or an oid 
}16 — end Called APtitle 
{17 - [3] Called Application-Entity Qualifier 
XXXXXX -- see 3.5 
}17 
? 
Calling AP-title and AE-qualifier may or may not be needed. 
{18 - [6] Calling Application-Process title 
XXXXXX -- see 3.5 
}18 
{19 - [7] Calling Application-Entity Qualifier 
XXXXXX -- see 3.5 
}19 
? 
-- the user information field may or may not be required 
-- (not required for Group I) 
{20 — [30] IMPLICIT SEQUENCE 
{21 — [EXTERNAL] 
XXXXXX -- [OID] This is the oid identifying the transfer 
-- syntax used for the user data. 
-—- It is (almost certainly) required even if only 
-- one transfer syntax was proposed. 
03 - [INTEGER] this is the pcid for the application 
- data 
XXXXXX -- [0] single-ASN.1-type - the application data 
= (see paragraph at end of this section below} 
}21 - end of EXTERNAL 
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-- conceivably there may be several EXTERNALS, probably in 
-- different presentation contexts (different pcids) 


200 00 }20 - end of user information field 

00 00 315 — end of AARQ 

00 OO }14 - end of single-ASN-type 

00 00 }13 - end of PDV-list 

00 00 }12 - end of Presentation User-data 

00 00 }7 - end of third element of CP-type SET 


00 00 }5 end of CP-type 

The application data carried in the EXTERNAL is shown (as AO La xxxx) 
assuming it is a single-ASN.1 type, which it often will be for group 
II (since these tend to be OSI applications). The xxxx will be the 
BER encoding of the application pdu (probably something like Z-BIND 
or Y- INITIALIZE). The length may be indefinite. 


If the application data is not a single ASN.1 type, but is an octet- 
aligned value, the AO La xxxx is replaced by 81 La xxxx, where xxxx 
is the value. In this case the length must be definite (unless an 
"unnecessary" constructed encoding is used.) 


Identical considerations apply to the other EXTERNALs carried in the 
ACSE pdus. 


6.2 Successful reply to connection setup 


If the connection attempt is successful, the following is sent to the 
initiator on a T-DATA. 


OE Ls {1 — ACCEPT SPDU 
a Ls ? 
05 06 {2 - Connect/Accept Item 
13 01 00 - Protocol Options 
ji Ls ? 
16 01 02 - version number (this shows version 2 only) 
—— if version 2 was not offered, omit all of {2} 
Ls ? 
14 02 0002 - Session User Requirements (functional units) 
- duplex fu only (kernel is automatic) 
K Ls ? 
Cl Ls {3 —- User Data. 
- CPA - P-CONNECT response 
31 80 {4 - [SET] 
-—- again, Mode-selector could come at the end 
AO 80 { - Mode-selector [0] 
80 01 01 - normal mode - [0], length=1, value=1 
00 00 } 
A2 80 {5 — [2] SEQUENCE (unnamed) 
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x La 
A5 80 
30 80 
80 01 
81 02 
00 00 
30 80 
80 01 
81 La 
00 00 
00 00 
* La 
61 80 
30 80 
02 01 
AO 80 
61 80 
a La 
Al 80 
06 La 
00 00 
A2 03 
02 01 
00 00 
A3 80 
Al 80 
02 01 
00 00 
00 00 
x La 
?BE 80 
Furniss 


{7 
00 
5101 


}7 
{8 


00 
XXXXXX 


}8 
}6 


{12 
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- [5] P-context-definition-result-list 
-- following result items are in the order 
—- corresponding to the pctx-definition-list in 
-- the connect 
-—- this example assumes that was ACSE, user, rubbish 
—-- with rubbish rejected 
— [SEQUENCE] result item for acse 
-- [0] result, value 0 is acceptance 
- [1] accepted transfer syntax name = BER 
- note that this has an implicit tag, not 06 
- end result item for acse p-ctx 


— [SEQUENCE] result item for application-data pctx 

- [0] value 0 is acceptance 

- [1] oid for transfer syntax, as on definition list 
-—- if there were several (groupIII) , the one you 

-—- liked most 

- end result item for app-data p-ctx 

- end p-ctx-def-result-list 


[APPLICATION 1] User-data, Fully-encoded 


[SEQUENCE] PDV-list 
— [INTEGER] value is pcid for ACSE, as stored from 
-—- the pcetx-definition-list on the P-CONNECT 
-- request 
- [0] single-ASN1-type 


A-ASSOCIATE response APDU - AARE 


{13 

? 

{14 
XXXXXX 


}14 
{15 
00 

}15 
{16 


{17 
00 
}17 


}16 
2 


— [APPLICATION 1] identifies AARE 


- [1] Application-context 
- [OID] name of application context 
—- usually the same as on AARQ, can differ 


- [2] result 
— [INTEGER] value 0 means accepted 


- [3] result-source-diagnostic 

- (curiously, a non-optional field) 

- [1] acse-service-user 

— [INTEGER] value 0 = null ! (why no implicit tag) 
- end acse-service-user 

- end result source diagnostic 


-- the user information field may or may not be required 


{20 


(not used for Group I) 
-— [30] IMPLICIT SEQUENCE 
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228 80 {21 - [EXTERNAL] 
-- the transfer-syntax oid is not present this time 
202 01 03 — [INTEGER] this is the pcid for the application 
- data 
?AO La xxxx -- [0] single-ASN1-type (see note at end of 6.1) 
200 00 }21 - end of EXTERNAL 


-- conceivably there may be several EXTERNALS, probably in 
-- different presentation contexts (different pcids) 


200 00 }20 - end of user information field 

00 00 313 —- end AARE 

00 00 312 - end single-asnl-type 

00 OO 311 —- end PDV-list 

00 00 310 - end Presn user-data 

00 00 }5 - end [2] implicit sequence in cpa 
00 00 }4 - end CPA-type set 


The following sequence are the octets need to reject a presentation 
context that was offered in the presentation-context-—definition-list. 
Since the result-list matches the definition list by position, it is 
placed at the corresponding point within {6} (e.g., it would come 
immediately after {8}, if the rejected context was the third one. 


—- next SEQUENCE is a rejection of a pctx 


30 80 {9 — [SEQUENCE] result item for a rejected pctx 

80 01 02 -- [0] result, value 2 is provider rejection 

82 01 00 - [2] reason, value 0 is reason-not-specified 
-—- there are other reasons, but let’s keep it 
-- simple 

00 00 }9 - end result item for rejected pctx 


6.3 Connection rejection 


Refusal is at session-level, but by session user, with no reason 
given. This is a compromise avoiding making unfounded accusations of 
(session) protocol misbehaviour. If the implementation finds it does 
not like the received message, it is not essential to attempt to 
communicate with the partner why, though this may be helpful if the 
reason is correctly identified. (In most cases, a wise implementor 
will make sure an error message goes somewhere or other). 


oc 03 {il — REFUSE SPDU 
a Ls ? 
32 01 00 - rejected by SS-user, no reason 


The far-end may send interesting things explaining why you are not 
getting interworking. If this is a session reason, the reason code 
will one octet between 81 and 86. If the rejection is higher than 
session, this will be carried on S-REFUSE (so first octet is still 
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OC) and the higher pdu will appear as part of the reason code, which 
will start with 02. (The only remaining code is 01 = user 
congestion.) 


6.4 Data-phase TSDU 


This is the core of the skinny stack. The lengths shown use a 
particular set of choices for indefinite and definite lengths that 
means that the application data length only affects one field. Making 
the two earlier indefinite lengths definite would require more 
calculation - adding 4 octets after the application data is assumed 
to be quicker. This header is also designed to be 20 octets long, 
thus maintaining 4-byte alignment between transport and application 
buffers. Implementations are recommended to use this encoding. It is 
possible to rapidly match incoming data against it - if there is no 
mismatch until the length field, the location of the beginning of the 
data can be determined without further analysis. 


SPDUs 
01 00 . — S-GIVE-TOKEN - required by basic concatenation 
— but no parameters 
S-DATA - no parameters - what follows is User 
Information, not User Data, so is not included in 
the SPDU length fields 
- P-DATA PPDU - TD (why TD ? Typed-data id TTD !) 


01 00 


61 80 {1 - User-data [APPLICATION 1] 
30 80 {2 — [SEQUENCE] PDV-list 
02 01 03 - [INTEGER] pcid for application data, P-CONNECT PPDU 


— remembered by both sides 

81 83yyyyyy XXXXXX —- [1] octet-aligned presentation data value(s) 
-—- length of length (3 octets) then three octets yyyyyy 
-- for the length of the user data xxxxxx 

00 00 }2 - End-of-contents for end of PDV-list 

00 00 31 - End-of-contents for end of Presentation User-data 


If the application data is in ASN.1, and a single ASN.1 value is 
being sent on the TSDU, the same header can be used except for the 
tag on the presentation data values, which becomes AO (= [0], 
constructed). 


If there are multiple data values to be sent, this header can be 
expanded in several ways: 


a) if there are several ASN.1 values from the same 
presentation context, they can be concatenated and 
treated as an octet-aligned value (using the header 
as shown above, with tag 81 (or Al - I think its 
primitive) or each ASN.1 value can be an item 
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(tagged A0), one after the other 


b) if the data values are from different presentation 
contexts (group IV), each is in its own {2} group 
within the {1}. 


On receipt, for the simple octet-aligned case, the data value may 
itself have a constructed encoding - this will make the tag Al, and 
it will contain elements each tagged 04 (OCTET STRING). According to 
CULR- 1, these elements are primitive (otherwise they would be 24 of 
course). 


6.5 Closedown - release request 


When all is done, and you want to close down gracefully, send this on 
T-DATA. 


— FINISH SPDU 


09 10 {21 - 9 identifies FINISH 
A Ls ? - No Transport Disconnect item 
- default is release Transport-connection 
Cl 0E {2 - User data (code 193) 
— P-RELEASE req/ind PPDU (has no name) 
61 80 {3 — [APPLICATION 1], user data, fully-encoded 
30 80 {4 — [SEQUENCE] PDV-list 
02 O01 O1 -—- pcid for ACSE, remembered from setup 
AO 80 {5 - [0] single asn.1-type 
- A-RELEASE request APDU - RLRQ 
62 80 {6 — [APPLICATION 2] identifies RLRQ 
80 01 00 - [0] reason, value 0 means normal 
K La ? 
-- the user information field may or may not be required 
- ( not required for Group I) 
?BE 80 {7 — [30] IMPLICIT SEQUENCE 
228 80 {8 — [EXTERNAL] 
-- the transfer-syntax oid is not present this time 
202 01 03 - [INTEGER] this is the pcid for the application 
- data 
?A0 La XXXXX —- [0] single-ASN.1-type application data 
—-- (see note at end of 6.1) 
200 00 }8 - end of EXTERNAL 
-—- conceivably there may be several EXTERNALS, probably in 
—- different presentation contexts (different pcids) 
200 00 }7 - end of user information field 
00 00 }6 — end of RLRQ 
00 00 }5 - end of single asn.1-type 
00 00 }4 - end of PDV-list 
00 00 }3 - end of Presentation User-data 
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6.6 Closedown - release response 


On receiving a FINISH, you send this to tell the other end it is all 


over 


200 
00 
00 
00 
00 


Ls 
Ls 


Session DISCONNECT SPDU 


{1 
{2 


— P-RELEASE 


80 
80 
01 
80 


{3 
{4 
01 
{5 


— A-RELEASE 


80 
01 
La 


80 


80 


01 


La 


00 


00 


00 


00 


00 
00 


{6 

00 

? 

—- the 
— (not 
{7 

{8 


03 
XXXXX 


}8 


- SI=10, DISCONNECT 
- User data 
rsp PPDU 
- [APPLICATION 1], user data, fully-encoded 
— [SEQUENCE] PDV-list 
—- [INTEGER] pcid for ACSE, remembered from setup 
- [0] single asn.1-type 
response APDU - RLRE 
— [APPLICATION 3] identifies RLRE 
- [0] reason, value 0 means normal 


user information field may or may not be required 
required for Group I) 
- [30] IMPLICIT SEQUENCE 
— [EXTERNAL] 
-- the transfer-syntax oid is not present this time 
— [INTEGER] this is the pcid for the application 
- data 
-—- [0] single-ASN.1-type application data 
-—- (see note at end of 6.1) 
- end of EXTERNAL 


-- conceivably there may be several EXTERNALS, probably in 
-- different presentation contexts (different pcids) 


}7 
}6 
}5 
}4 
}3 


- end of user information field 
- end of RLRE 
- end of single asn.1-type 
- end of PDV-list 
- end of Presentation userdata 


6.7 Deliberate abort 


It is not clear whether this is any use - just clearing the Transport 
connection will be more effective. It goes on T-DATA, but asks for 
far-side to close the T-connection. 


the 


19 
11 


Furniss 


Ls 
01 


Session ABORT SPDU 


{1 
03 


- SI of 25 is ABORT 

- Transport Disconnect PV, code 17 
-—- value = ’...00011’b means please 
-- release T-conn, user abort 


-— Session User Data 
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AO 
AO 
30 
02 
06 
00 


30 
02 
06 
00 
00 
61 
30 
02 
AO 


64 
80 


?BE 
228 
202 
?A0 
?00 
?00 
00 
00 
00 


00 
00 
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— P-U-ABORT PPDU - ARU 


80 
80 
80 
01 
02 
00 


80 
01 
La 
00 
00 
80 
80 
01 
05 


{3 —- [0] implicit sequence for normal mode 
{4 - [0] presentation-context-identifier-list 
{5 — [SEQUENCE] 
01 — [INTEGER] pcid for ACSE 
5101 - [OID] for acse transfer syntax = BER 
}5 
-- there will be one {6} group for each application 
-- presentation context that is used in this message 
-- if there is no user data, the {6} group can be 
—- omitted 
{6 
03 —- [INTEGER] pcid for application data 
XXXXXX - [OID] transfer syntax for application data 
}6 
}4 - end of presentation-context-identifier-list 
{7 — [APPLICATION 1], user data, fully-encoded 
{8 — [SEQUENCE] PDV-list 
01 — [INTEGER] pcid for ACSE as on CP PPDU 
{9 - [0] single asn.1-type 


— A-ABORT APDU - ABRT 


80 
01 


80 
80 


01 


La 


00 


00 
00 
00 
00 
00 
00 


{10 — [APPLICATION 4] identifies ABRT 
01 - [0] value 1 is acse-service-provider 
-- the user information field may or may not be required 
{11 — [30] IMPLICIT SEQUENCE 
{12 — [EXTERNAL] 
-- the transfer-syntax oid is not present this time 
-—- (according to CULR-1) 
03 - [INTEGER] this is the pcid for the application 
- data 
XXXXX —- [0] single-ASN.1-type application data 
-—- (see note at end of 6.1) 
}12 - end of EXTERNAL 
-- conceivably there may be several EXTERNALS, probably in 
—- different presentation contexts (different pcids) 
FIN - end of user information field 
}10 —- end of ABRT 
}9 - end of single asn.1-type 
}8 - end of PDV-list 
}7 - end of Presentation user-data 
}3 — end of ARU-PPDU 
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6.8 Provider abort 


Generated when an internal error occurs (i.e., something has gone 
mildly (?) wrong in the cookbook implementation). Rather than accuse 
anyone of protocol errors, we just abort at session. 


ABORT SPDU 
19 03 {1 — SI=25 = ABORT SPDU 
11 01 09 - Transport Disconnect PV, code 17 
—-- value = ’...01001’b release T-conn 


-- no reason 
x is: 2: 


6.9 Abort accept 


If a Session abort (of any kind) is sent, it is possible that the 
far-end will send back an abort accept. If this happens, disconnect 
the transport. (The abort messages above do not propose that the 
transport connection be reused, and in this case, an abort accept is 
just the far-end passing the transport-disconnect initiative back.) 
This session message need never be sent - just disconnect transport 
on receiving an abort. 


ABORT ACCEPT SPDU 
1A 00 - — SI=26 = ABORT ACCEPT SPDU, no parameters 
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8. Other Notes 


The Session, Presentation and ACSE standards have been the subject of 
considerable amendment since their first publication. The only one 
that is significant to this cookbook is Session addendum 2, which 
specifies session version 2 and unlimited user data. New editions of 
these standards, incorporating all the amendments, will be published 
during 1994. 
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10. 


The coding choices made in the cookbook are (nearly) those made by 
the "Canonical Encoding Rules", which are a form of Basic Encoding 
Rules with no optionality, specified in the new edition of ISO/IEC 
8825. A defect report has been proposed against Presentation and 
ACSE, suggesting that a note to the protocol specifications recommend 
use of the canonical encoding options when sending, and then 
optimising for this on receipt. 


Security Considerations 

Security issues are not discussed in this memo. 
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